為什麼想挑戰這個題目？

這半年看了不少 MCP、Agent、Multi-Agent 的文章，很多教學第一步都是：

client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

API 很方便，但當我開始玩 Agent 之後，發現一個很現實的問題：

會捨不得一直測。

單次呼叫可能沒多少錢，但 Agent 一跑就是好幾次模型請求，Multi-Agent 再一次開好幾個 Agent，測試次數一多，成本自然就上來了。

更重要的是，雲端 API 把很多底層細節包掉了。

像是：

• 模型到底花多少時間載入？
• 同時跑多個 Agent，真的有比較快嗎？
• 一張 GPU 同時扛很多 Agent，瓶頸會在哪？
• 不同模型來回切換，成本到底有多高？

所以這次鐵人賽，我想換個玩法：

三十天全部跑本機，零付費模型 API。

而且文章裡出現的程式和結果，我都會真的跑過。

跑得漂亮就貼漂亮的。

跑炸了……那也照貼 XD

這三十天要做什麼？

這系列不會是三十篇互不相關的小範例。

我打算一路把同一個專案往上疊：

Day 1-5    Python 與本機模型基礎
Day 6-10   MCP 協定與 MCP Server
Day 11-20  Agent、ReAct、LangGraph、Google ADK
Day 21-30  Multi-Agent、OpenClaw、效能與 NVIDIA PAIR

前面幾天可能看起來比較基礎，但後面會慢慢接回來。

例如 Pydantic 會接到 MCP Tool Schema，async 會接到 MCP 通訊，decorator 最後則會看到 @mcp.tool()。

我不想只知道「這段貼上去可以跑」。

比較想知道它底下到底在做什麼。

我的測試環境

這次主要使用：

OS      Ubuntu 24.04.4 LTS
GPU     NVIDIA GB10
記憶體  121 GB
Ollama  0.32.14

硬體算是比較特殊，不過這系列並不限定一定要同一台機器。

只要你的電腦能跑 Ollama，大部分內容都可以跟著做，模型換小一點就好。

Day 1：先選模型

既然後面三十天幾乎都會用到本機 LLM，那第一天我不想先寫 Hello World。

我想先知道：

哪個模型最適合當接下來的主力？

今天測了六個模型：

nemotron-3.5-lightning:30b
gpt-oss:20b
gemma4:12b
mistral-small3.2:24b
qwen3:32b
llama3.2:3b

第一輪先問所有模型同一題：

用一句話說明什麼是 MCP？

結果速度差距比我預期還大。

nemotron-3.5-lightning:30b   86.4 tok/s
llama3.2:3b                  59.7 tok/s
gpt-oss:20b                  56.3 tok/s
gemma4:12b                   25.9 tok/s
mistral-small3.2:24b         12.6 tok/s
qwen3:32b                     9.9 tok/s

其中 nemotron-3.5-lightning:30b 跟 qwen3:32b 都是 30B 左右，但速度差了快九倍。

所以模型大小真的不能直接等於推論速度。

比速度更有趣的是：有些模型真的會亂講

六個模型回答 MCP 時，看起來其實都很像一回事。

但仔細看就會發現，有些答案其實已經偏掉了。

例如有模型把 MCP 說成：

用來定義機器學習模型輸入、輸出、版本與部署需求的協定。

也有模型直接把它講成：

多台電腦之間的通訊協定。

文字都寫得很像技術文件，但內容不一定正確。

這也是我這次很想觀察的地方。

本機模型不是不能用，但不能因為它講得很有自信，就直接相信。

後面做 Agent 時，我會比較把模型定位成「負責判斷與操作工具的人」，而不是什麼都靠它自己知道。

第二輪：Tool Calling

Agent 最重要的能力之一，就是模型能不能正確決定何時呼叫工具。

所以第二輪我準備了一個簡單的：

get_weather

然後問：

台北現在天氣如何？

結果六個模型全部成功產生 Tool Call。

這點比我原本預期還好。

不過也看到一個有趣的小差異。

有人傳：

{"city": "Taipei"}

有人傳：

{"city": "台北"}

還有模型直接省略有預設值的參數。

也就是說：

Schema 一樣，不代表不同模型會產生完全一樣的輸入。

這件事情後面自己寫 Agent Loop 時應該會很重要。

第一個效能坑也出現了

測 Tool Calling 時，我還注意到另一件事。

nemotron 熱機後原本只需要大約：

5.3 秒

但模型重新載入時，變成：

56.9 秒

差了快十倍。

這讓我開始很好奇後面的 Multi-Agent。

如果：

Planner    用 Model A
Coder      用 Model B
Reviewer   用 Model C

結果三個模型都塞在同一張 GPU 上。

那我們以為自己在做 Multi-Agent，最後會不會其實只是三個 Agent 排隊等模型載入？

這個問題先留著，Day 28 再來實測。

最後的模型選擇

Day 1 跑完後，我先決定三個角色：

MODEL_MAIN  = "nemotron-3.5-lightning:30b"
MODEL_SMALL = "llama3.2:3b"
MODEL_ALT   = "gpt-oss:20b"

nemotron 當主要模型。

llama3.2:3b 留給之後需要大量並行的實驗。

gpt-oss:20b 則當對照組，拿來測不同模型之間的 Tool Schema 相容性。

Day 1 小結

第一天本來只是想選模型，結果已經先看到幾個後面一定會再遇到的問題：

• 模型大小差不多，速度可能差很多
• 模型講得很專業，不代表內容正確
• 同一份 Tool Schema，不同模型輸出還是會有差異
• 本機 Agent 的瓶頸可能不是 Framework，而是模型載入和 GPU

接下來三十天，我會繼續從這台機器往上蓋。

不接付費模型 API，能在本機完成的就盡量在本機完成。

明天：Day 2

下一篇先處理：

型別提示、dataclass 與 Pydantic。

因為再過幾天開始寫 MCP Tool 時，就會碰到一個很重要的東西：

JSON Schema。

而 Pydantic，剛好就是我們從 Python 世界走到 MCP Tool Schema 的第一座橋。

明天繼續。